This article breaks down the “agent harness” as the orchestration layer—prompts, tool interfaces, loops, memory, guardrails—around foundation models. It argues that teams accumulate hidden technical debt when they treat harnesses as permanent and shows why training and production harnesses must differ to avoid failures as models evolve.

• Harness code (prompts, tool wrappers, loops, guardrails) becomes obsolete as models improve, so teams treating it as permanent architecture waste months later ripping it out
• Research harnesses need broad, open tool access so optimizers can learn new capabilities, while production harnesses need strict allowlists, scoped credentials, and deny-by-default controls—using one harness for both either stifles learning or creates security risk
• "Inner" harnesses (built by the model/agent developer) and "outer" harnesses (built by end users via skills, MCP servers, custom agents) evolve on different timelines and accumulate separate technical debt